As a Haskeller, this function confused me briefly, as its either :: (a -> r) -> (b -> r) -> Either a b -> r function is also typically called with two arguments, but does something very different.
While Haskell isn't Nix, Nix does have an attrset shape close to Rust's Err type, which is isomorphic to Either, which sees similar use. This would be the shape of the return value of tryEval.

A problem with the name "either" is that in natural language use, it does not convey a bias towards the one or the other. (And also the Haskell type suffers from this, coincidentally)

These two reasons lead me to believe that a better name could be found for this function.
I'd be ok with coalesce from SQL (only objection being that variable arity could be thought of as a list, which I would not advocate for, but marks a difference).
Other ideas would be

• fallback (suffering from the same lack of "bias")
• otherwise, requiring that you imagine the function name between the arguments, which is not too uncommon I think
  • orElse
• orNullable (hinting at the "nullable" family of functions; this would be the 3rd member)

Definitiely a 👍 for adding a function that performs this pretty fundamental operation

orElse collides with the rust convention of fn or_else(&self: &C<T>, other: impl Fn() -> T) -> C<T>. The rust name for the null coalescing function is or, which is already taken in nixpkgs. unless is slightly shorter an option in the same vein as otherwise, with behavior kinda similar to the lisp macro unless.

Other ideas would be ...

I feel like these don't read all that well in regular function form, but would read great with the pipe operator:

null |> fallback "foo"
null |> otherwise "foo"
null |> orElse "foo"
null |> orNullable "foo"

vs.

fallback null "foo"
otherwise null "foo"
orElse null "foo"
orNullable null "foo"

Alas, we are not there yet... But maybe looking ahead?

As it stands, I feel like coalesce/fallback read the best imo.

Edit: Actually my assumption with the pipe operator might be wrong, need to re-check the RFC.

Of the names suggested so far, fallback is definitely my favorite. Some other ideas, that try to clarify bias:

• prefer (with the idea of an implicit "over" between the arguments, resulting in the sentence "Prefer A over B."
• try (matching the idea of a try/catch block)

I like prefer, and it makes me think of an alternate idea that may be clearer as a user. Rather than taking two values as arguments, it would take a list of values, and simply return the first value that wasn't null. The order of the values would represent the preference. I think this method of interaction makes it clearer which values will be preferred.

Don't want to bikeshed, though - just another idea that shouldn't prevent this PR from being merged.

I prefer otherwise: prefer sounds like a priority thing (cf. mkOverride or hiPrio/loPrio); try sounds too much like error handling, which it isn't; coalesce sounds way too complex for what it is and IMO may obfuscate its meaning, especially for non-native English speakers; unless might confuse people coming from Perl/Ruby as it's an if with an inverted condition there; and either confuses my Haskell brain for aforementioned reasons.

After sleeping on it, my favorite so far is definitely fallback:

lib.fallback foo.bar.baz "default"

I read it as: fallback foo.bar.baz on "default". I don't feel like it lacks bias.

I agree this is a useful thing to have.
However: What about a scenario with multiple potentially null values? Might it make sense to also expose something like the following?

first_non_null = builtins.foldl' either null;

It'd operate on a list:

nix-repl> first_non_null [ null null 5 null "test" null 7]
5
nix-repl> first_non_null [ true null null 5 null "test" null 7]
true
nix-repl>

If we have either, this is trivial to build. But it'd feel right to have a "multi-fallback" too if we have a pairwise fallback.
Note this is not immediately equivalent to filtering for non-null and taking the first element. Taking the first element would fail to eval if no elements are non-null, while this would return null at the very end.

If we're talking about a list fallback variant, then I would definitely want it to be a separate function yeah. I feel like it should be as close to the original if then else as possible and not allocate extra thunks or loop without early exit.

It's worth considering a name that would be applicable to both variants in that case, though that certainly makes thing more difficult. Maybe fallbackChain/fallbackList/lib.lists.fallback?

I don't know... Personally I feel like the vast majority of the time I just want the basic fallback a b so I'm not really all that invested in the list variant.

After sleeping on it, my favorite so far is definitely fallback:

lib.fallback foo.bar.baz "default"

I read it as: fallback foo.bar.baz on "default". I don't feel like it lacks bias.

Does it make sense to reverse the arguments?

map (lib.fallback "default") [ "a" null "b" null ]

This could be made clearer in the name, too, like lib.fallbackTo or lib.defaultTo.

I kinda prefer the fallback happening from left to right, but you're right that usually functions in Nix are written with partial application in mind, in which case it makes sense for the fallback value to come first. lib.fallbackTo/lib.defaultTo are definitely more fitting names imo if we go with that variant.

I'm happy to change it to any of these if there's consensus.

Changed the implementation to defaultTo and swapped arguments. Let me know what you think.

Successfully created backport PR for release-24.11:

• [Backport release-24.11] lib: add defaultTo #367441